Enhanced server to client session inspection

ABSTRACT

In one embodiment, a technique for enhancing the inspection of data sent from a server is provided. By modifying a client request in an effort to prevent the transformation (e.g., encoding and/or compression) of data by the server, unencoded data may be received, which can be inspected without the overhead associated with first decoding the data. Further, in the event the data is encoded despite modifying the client request to prevent such encoding, the server may be untrustworthy and one or more appropriate actions may be taken.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention generally relate to networksecurity.

2. Description of the Related Art

Some network protocols, such as certain versions of Hypertext TransferProtocol (HTTP), allow for the transparent use of compression andencoding algorithms in sessions between a client and server. Becausecertain data, such as web pages, tend to compress well, the use ofcompression may significantly improve network performance, while the useof encoding (e.g., in encryption algorithms) is important in maintainingsecurity.

As a result, however, current network security devices, such asintrusion protection systems (IPSs) face the problem that a server cansend malicious traffic compressed and/or encoded to a “victim” client.Writers of such malicious content can exploit the fact that many IPSdevices cannot inspect encoded or compressed HTTP sessions. In order toinspect such traffic, an ISP would have to first decompress/decode thetraffic for inspection, which may not be feasible at high speeds.

Accordingly, what is needed is an improved technique for inspectingserver to client traffic in a session.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features of the presentinvention can be understood in detail, a more particular description ofthe invention, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. Itis to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

FIG. 1 illustrates an example network topology in accordance withembodiments of the present invention.

FIG. 2 is a flow diagram of example operations in accordance withembodiments of the present invention.

FIGS. 3A-3D illustrate traffic flow through the example topology of FIG.1 in which a server complies with a request to disablecompression/encoding, in accordance with embodiments of the presentinvention.

FIGS. 4A and 4B illustrate traffic flow through the example topology ofFIG. 1 in which a server does not comply with a request to disablecompression/encoding, in accordance with embodiments of the presentinvention.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Embodiments of the present invention allow for the efficient inspectionof server to client traffic during a network session. An inspectiondevice may modify a header in a client request in an effort to preventencoding and/or compression of data sent from the server. As a result,the inspection device may receive unencoded and uncompressed data thatit may inspect without the overhead of decoding and decompression. Ifthe server sends data that is encoded and/or compressed despite themodified client request, the server may be sending malicious data andthe inspection device may take appropriate action.

Embodiments of the present invention will be described below withreference to examples of inspecting traffic in Hypertext TransferProtocol (http) sessions. However, those skilled in the art willrecognize that the http is merely an example of one type of networkprotocol that supports encoding and compression and will appreciate thatthe techniques described herein may be applied to any type of networkprotocol that allows encoding and compression to be enabled and disabledin client requests.

Embodiments of the present invention will be described below withreference to an in-line device (positioned between a client and server)that performs inspection of traffic as described herein. However, thoseskilled in the art will recognize that the techniques described hereinmay also be performed by a device positioned at a different location,such as a component that is part of a client.

An Example Network Environment

FIG. 1 illustrates one example of a network environment 100 in whichembodiments of the present invention may be utilized. The environmentgenerally includes a client 102 that communicates with a server 104 viaa network 106. The network 106 may be include any combination ofsuitable elements to route traffic between the client 102 and server104, including a “fabric” of network nodes, such as switches androuters. The network 106 may be include a company Intranet or theInternet.

An intrusion prevention system (IPS) device 108, or other type ofinspection device, may be utilized to monitor traffic between the clientand server during a session. As illustrated, the IPS device 108 may belocated between the network 106 and client 102, which allows it tomonitor traffic between the client 102 and any server the client 102communicates with over the network 106. Further, for some embodiments,the IPS device 108 may be positioned at the attachment point of a localnetwork (e.g., a company Intranet) to the network 106, allowing the IPSdevice 108 to monitor traffic between multiple clients of the localnetwork and servers via the network 106.

As previously described, if encoding and/or compression are enabled in asession between the client 102 and server 104, the IPS device 108 wouldfirst have to decode and/or decompress the traffic in order to inspectit. To facilitate the following description, the generic term “encoding”will be used to refer collectively to any form of transforming data,including encryption, compression, or a combination thereof, while thegeneric term “decoding” will be used to collectively refer to any typeof decoding, decryption, decompression, or a combination thereof.

If some form of encoding is enabled for a session, the additionaloverhead associated with decoding traffic for inspection may have asignificant adverse impact on network traffic. For some embodiments,however, the IPS device 108 may be configured to overcome some of thisadverse impact and enable enhanced inspection of session traffic.

FIG. 2 illustrates example operations 200 that may be performed by theIPS device 108 to achieve enhanced traffic inspection. The operationsmay be described with reference to FIGS. 3A-3D and FIGS. 4A and 4B,which illustrate example session traffic inspected by the IPS device108.

The operations begin, at step 202, when the IPS device receives arequest from a client enabling encoding in session traffic. Exactly howencoding is enabled may depend on the particular protocol being used ina session. For example, as illustrated in FIG. 3A, in an HTTP session aclient request 310 may have an “Accept-Encoding” header line 312 withfields that specify what types of encoding will be allowed. In theillustrated example, if the request 310 were allowed to reach the server108, the Accept-Encoding line 312 would indicate that “compression” and“gzip” encoding is allowed for the session.

At step 204, however, the IPS device modifies the client request in aneffort to prevent the server from sending encoded data. For example, asillustrated in FIG. 3B, the IPS device 108 may modify the request 310 toremove the fields in the Accept-Encoding header line 312. The resultingmodified request 320 may have either no fields listed in itsAccepted-Encoding header line 322, as shown. As an alternative, the IPSdevice 108 may remove the Accepted-Encoding header line altogether, ordisable all listed forms of encoding (e.g., by specifying a zero“qvalue”).

At step 206, the IPS device sends the modified request to the server. Atstep 208, the IPS device receives (response) data from the server. Atstep 210, the IPS device determines whether or not the data is encoded.If the server complies with the request (e.g., honors the request for noencoding), the data received from the server will be unencoded. FIG. 3Cillustrates a server response 330 with unencoded data 332.

If the data is not encoded, the IPS device can proceed to inspect thedata, at step 212. The inspection may involve any known or proprietarytype of inspection, for example, using pattern matching corresponding toknown malicious attacks. If the results of the inspection indicate thedata is not malicious, the IPS device forwards the data to the client,at step 216. As illustrated in FIG. 3D, the IPS device 108 forwards theresponse 330, as received from the server, to the client 102 withoutmodification.

In expected operation, modifying the client request to remove encodingrequests should result in the server sending back requested data in anunencoded (uncompressed and unencrypted) form which may be easilyinspected. To comply with some versions of HTTP, servers must supportthe lack of encoding since some browsers cannot support it.

Therefore (referring back to step 210), if the server response containsencoded data despite the request for no encoding in the modified requestsent from the IPS device, it may be an indication that the server cannot be trusted. If the response contains encoded data, some type ofaction may be taken, at step 218.

The type of action taken may vary depending on the particular embodimentand/or depending on the particular configuration of the IPS device 108.For example, the IPS device 108 may be configured to simply block theresponse, and not send it to the client 102. For some embodiments, theresponse may be stored (e.g., quarantined) and some type of notificationmay be generated, such as an e-mail to an administrator.

For some embodiments, the IPS device 108 may decode the data and inspectit. If the results of the inspection indicate the data is not malicious(despite the unrequested encoding), the IPS device 108 may forward theresponse on to the client. If the results of the inspection indicate thedata is malicious, however, the IPS device 108 may block the responsefrom reaching the client 102.

For some embodiments, the IPS device 108 may be configured to modify (or“clean”) the response, for example, to remove attachments or other datathat was encoded or, when decoded, revealed suspect material. Thisscenario is illustrated in FIGS. 4A and 4B, in which the IPS device 108receives a response 430 from the server 104 that has encoded data 432.The IPS device 108 modifies the response (e.g., removing suspectportions) and forwards the modified response 440 to the client 102.

For some embodiments, the IPS device 108 may be configurable, allowing auser (e.g., an administrator) to select one or more actions to take, forexample, via a graphical user interface (GUI) screen. For example, theuser may be able to specify what actions to take, appropriate personnelthat should be notified (e.g., via phone number or e-mail address) inthe event a suspect response is received from server. Once theselections are made, instructions may be sent to the IPS device, forexample, via a command line interface (CLI) to configure it according tothe selected options.

The techniques described herein may be utilized to enhance inspection ofserver to client traffic. By modifying outbound requests (e.g., HTTPrequests), an intrusion prevention system may prevent encoding, allowingfor inspection of data which may not otherwise be inspected without thesubstantial overhead involved in decoding. Further, the mere receipt ofencoded data from a server despite a request to not use encoding mayidentify a server as untrustworthy.

The examples above described removing all requests for encoding, forexample, by removing all fields in an Accept Encoding header line orremoving the Accept Encoding header line altogether. However, for someembodiments, similar techniques may be applied while still allowing oneor more specified forms of encoding. For example, rather than modify aclient request to prevent all forms of encoding, the IPS device maymodify the request to prevent only some forms of encoding. If the serverresponse contains data that is unencoded or data that is encoded usingone of the allowed forms of encoding, the IPS device may forward theresponse to the client (possibly decoding and inspecting it first). Onthe other hand, if the server response contains data that is encoded ina form that was not indicated in the request, the IPS device may takeaction as described above. Such flexibility may allow some forms ofencoding (e.g., that have not been associated with known maliciousattacks) while preventing others.

As previously described, for embodiments, the operations describedherein may performed at a client (e.g., by a client component ratherthan a separate IPS device). In such embodiments, upon detecting encodeddata and/or malicious content, a client component performing theinspection may take actions to remove the malicious content or preventthe response data from being forwarded on (e.g., to a downstreamcomponent), for example, depending the component configuration.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

1. A method comprising: receiving a client request for data from a server, the request including a specification of one or more forms of transforming response data sent by the server in response to the request; modifying the request in a manner designed to prevent the server from transforming the response data in accordance with the specification; sending the modified request to the server; receiving response data from the server; if the response data is not transformed in accordance with the specification, inspecting the response data for malicious content; and if the response data is transformed in accordance with the specification, taking one or more predetermined actions.
 2. The method of claim 1, wherein the one or more forms of transforming response data comprise one or more forms of compression.
 3. The method of claim 1, further comprising, if the response data is not transformed in accordance with the specification and malicious content is found in the response data, removing the malicious content from the response data prior to forwarding the response data.
 4. The method of claim 1, further comprising, if the response data is not transformed in accordance with the specification and malicious content is found in the response data, preventing the response data from being forwarded.
 5. The method of claim 1, wherein: the specification comprises one or more fields in a Hypertext Transfer Protocol (HTTP) header; and modifying the request in a manner designed to prevent the server from transforming the response data in accordance with the specification comprises at least one of modifying or deleting the fields.
 6. The method of claim 1, wherein taking one or more actions comprises preventing the response data from reaching the client.
 7. The method of claim 1, wherein taking one or more actions comprises decoding the response data to generate untransformed response data and inspecting the untransformed response data.
 8. The method of claim 7, further comprising: detecting malicious content in the untransformed response data; modifying the response data to remove the malicious content; and forwarding the modified response data.
 9. A method comprising: receiving a request, the request including a specification of one or more forms of transforming response data sent by a server in response to the request; modifying the request to remove at least one of the forms of transforming from the specification; sending the modified request to the server; inspecting response data from the server for malicious content if the response data is not transformed or is transformed using a form of transforming specified in the modified request; and taking one or more predetermined actions if the response data is transformed using a form of encoding that is not specified in the modified request.
 10. The method of claim 9, wherein: the specification comprises one or more fields in a Hypertext Transfer Protocol (HTTP) header; and modifying the request comprises at least one of modifying or deleting the fields in the HTTP header.
 11. The method of claim 9, wherein taking one or more predetermined actions comprises decoding the response data and inspecting the decoded response data.
 12. The method of claim 9, wherein taking one or more actions comprises sending a notification to a user.
 13. The method of claim 12, further comprising receiving an identification of the user via an interface.
 14. An inspection device, comprising: an interface for receiving client requests and responses from a server; and logic configured to receive a request that includes a specification of one or more forms of transforming response data sent by a server in response to the request, modify the request to remove at least one of the forms of transforming from the specification, send the modified request to the server, inspect response data from the server for malicious content if the response data is not transformed or is transformed using a form of transforming specified in the modified request, and take one or more predetermined actions if the response data is transformed using a form of encoding that is not specified in the modified request.
 15. The device of claim 14, wherein the one or more forms of transforming response data comprise one or more forms of compression.
 16. The device of claim 14, wherein the logic is configured to, if the response data is not transformed or is transformed using a form of transforming specified in the modified request and malicious content is found in the response data, remove the malicious content from the response data prior to forwarding the response data.
 17. The device of claim 14, wherein: the specification comprises one or more fields in a Hypertext Transfer Protocol (HTTP) header; and modifying the request in a manner designed to prevent encoding of data sent to the client from the server comprises at least one of modifying or deleting the fields in the HTTP header.
 18. The device of claim 14, wherein the one or more predetermined actions comprise preventing the response data from being forwarded by the device.
 19. The device of claim 14, wherein the one or more actions comprise decoding the response data to generate untransformed response data and inspecting the transformed response data.
 20. The device of claim 14, wherein the logic is further configured to: detect malicious content in the transformed response data; modify the response data to remove the malicious content; and forward the modified response data. 